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(57) Abstract: The invention concerns a method and an architecture for remote monitoring, via an Internet-type network {RI), a 
user station (1) comprising a smart card reader (3). The data required for momtoring the station (1) are stored in a distant server (4). 
The station (1) comprises a Web-type browser (10) transmitting requests to the server (4). In response, the latter produces specific 
commands designed for the smart card (2). The station (1) comprises a specialised software module (8) forming an interface between 
the smart card reader (2) and the Internet network (RI). Said module translates the specific commands into commands in conformity 
with the ISO 7816-4 standards, and transmits them to the smart card (2) to activate an application thereof. The server (4) may also 
store (42) HTML pages. The smart card (2) transmits, via the specialised software module (8), a reply to the distant server (4) which 
processes it and retransmits the data to the browser (10) to be displayed on a screen (5). The invention is particularly applicable to a 
smart card (2) demonstrator. 

[Suite sur la page suivante] 
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En ce qui concerne les codes a deux lettres et autres abrevia- 
tions, se referer aux "Notes explicative* relatives aux codes et 
abbreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCT. 



(57) Abrege: L* invention concerne un proce'de' et une architecture de pilotage a distance, via un reseau de type Internet (#/), d'une 
station d'utilisateur (1) comprenant un lecteur de carte a puce (3). Les donnees necessaires au pilotage de la station (1) sont stockees 
(41) dans un serveur eloigne* (4). La station ( 1 ) comprend un navigateur de type "WEB" (10) transmettant des requeues au serveur (4). 
En response, celui-ci elabore des commandes specifiques destinees a la carte a puce (2). La station (1) comprend un module logiciel 
specialist (8) formant interface entre le lecteur de carte a puce (3) et le reseau Internet (RJ). Ce module (8) traduit les commandes 
specifiques en commandes conformes aux normes ISO 7816-4, et les transmet a la carte a puce (2) pour activer une application de 
celle-ci. Le serveur (4) peut stocker (42) egalement des pages "HTML". La carte a puce (2) transmet, par rinterme'diaire du module 
logiciel specialist (8), une reponse au serveur eloigne* (4) qui la traite et re transmet des donnees au navigateur (10) pour afficnage 
sur un ecran (5). Application notamment a un demonstrateur de carte a puce (2). 
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Titre : Precede et architecture de pilotage a distance d'une station utilisateur via 
un reseau detype Internet et leur application a un demonstrateur de carte a puce. 

L'invention concerne un procede de pilotage a distance d'une station 
d'utilisateur munie d'un lecteur de carte a puce via un reseau de type Internet. 

L'invention concerne egalement une architecture permettant la mise en 

ceuvre d'un tel procede. 
5 L'invention s'applique notamment a un demonstrateur de carte a puce. 

Dans le cadre de l'invention, le terme "station d'utilisateur" doit etre 
compris dans un sens general. La station precitee peut etre notamment 
constituee par un ordinateur personnel fonctionnant sous divers systemes 
d'exploitation, tels WINDOWS ou UNIX (tous deux etant des marques 
10 deposees). Elle peut etre aussi constituee par une station de travail, un 
ordinateur portable ou un terminal de carte, dit dedie. Dans ce qui suit, une telle 
station d'utilisateur sera appelee simplement "terminal". 

De meme, dans le cadre de l'invention, le terme "reseau Internet" 
englobe, outre le reseau Internet proprement dit, les reseaux prives 
18 d'entreprises ou similaires, dits "intranet", et les reseaux les prolongeant vers 
I'exterieur, dits "extranet". 

Les cartes a puce sont utilisees dans divers domaines : applications 
bancaires, de sante, comme "porte-monnaie" dit electronique, etc. Sur une carte 
a puce peuvent en outre coexister plusieurs applications (carte a puce multi- 

20 application). 

Lorsqu'une nouvelle application est rendue disponible sur une carte a 
puce, il est souhaitable de pouvoir disposer de terminaux, dedies ou non, pour 
organiser des seances de formation, notamment pour presenter les 
fonctionnalites de cette carte et ses possibles. Ces seances de formation ou 

25 de presentation peuvent s'adresser a des publics tres divers : personnel de 
maintenance, vendeurs, voire usagers fmaux. Le contenu pedagogique et la 
forme des prestations a fournir doivent en general etre adaptes au public vise. 

Dans I'art connu, les solutions traditionnellement proposees pour la 
realisation d'une station de demonstration de carte a puce, que Ton appellera ci- 

30 apres simplement "demonstrateur", font appel a une configuration a base 
d'ordinateur individuel et a des programmes specifiques de pilotage du terminal 
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et cle son lecteur de carte a puce. Ces programmes sont le plus souvent ecrits 
dans un langage du type Basic, C++ ou JAVA (marques deposees). 

Cette solution, si elle ne necessite pas generalement un materiel 
particulierement couteux (simple ordinateur individuel), n'est pas pour autant 
5 exempte d'inconvenients et parmi lesquels les suivants : 

- les programmes specifiques precites sont le plus souvent volumineux ; 

- leur mise en place est egalement longue et complexe ; 

- il est necessaire de sauvegarder les programmes nouvellement 
implantes dans la machine et, lors de la premiere mise en place, si la machine 

10 ne comporte pas de programme permettant une sauvegarde sur un peripherique 
specialise, type "IOMEGA" (marque deposee) ou similaire, il est necessaire de 
surplus d'implanter un tel programme ; 

- pour chaque mise a jour de I'application enregistree sur la carte a 
puce ou lorsque le contenu de la demonstration est different (adaptation au 

15 public concerne par exemple), il est necessaire de reiterer les processus 
' rappeles ci-dessus ; et 

- pour les operateurs, I'apprentissage du mode operatoire d'un logiciel 
ecrit dans les langages rappeles ci-dessus demande du temps, car leurs 
interfaces graphiques ne sont pas normalisees : les operateurs doivent done 

20 etre specialises, ce qui peut entrainer des couts supplementaires. 

On doit ajouter que, si plusieurs terminaux sont utilises aux fins de 
demonstration, les inconvenients precites se repetent pour chacun de ces 
terminaux : il est notamment necessaire de charger x fois le meme programme, 
si x est le nombre de terminaux, ces derniers pouvant etre tres eloignes les uns 

25 des autres. Meme si Ton recourt a des procedures de telechargement a partir 
tfun serveur central, il est quand meme necessaire de s'assurer que la version 
de logiciel. presente dans tous les terminaux est identique. Des procedures 
specifiques d'administration sont done necessaires. 

D'autre part, avec le developpement du reseau Internet, il serait 

30 souhaitable de pouvoir piloter a distance les terminaux de presentation, via 
precisement ce reseau et en faisant usage des protocoles de transmission 
standards utilises sur celui-ci. 
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Des solutions de ce type ont ete proposees. Cependant ces solutions 
ne sont pas non plus exemptes d'inconvenients. Elles necessitent en effet de 
telecharger ou d'implanter dans le terminal, pour chaque application de 
demonstration, une piece de logiciel specifique connue sous I'appellation anglo- 
saxonne "plug-in", generalement ecrite en langage C ou C++, pour que ce 
terminal puisse communiquer avec la carte a puce, via un lecteur de carte a 
puce. Les pieces de logiciels precitees souffrent des memes defauts que ceux 
evoques ci-dessus : code volumineux qu'il faut installer ou telecharger avant 
chaque demonstration, interfaces graphiques non normalisees, etc. Comme 
precedemment, il n'est pas en effet possible d'installer une fois pour toutes un 
"plug-in", car celui-ci depend notamment, outre du type de navigateur utilise, de 
('application en demonstration et de la version des programmes de pilotage. 

(.'invention, tout en remplissant les besoins qui se font sentir, vise a 
pallier les inconvenients des procedes et dispositifs de Tart connu, et dont 
certains viennent d'etre rappeles. 

L'invention se fixe pour but un procede et une architecture de systeme 
permettant de piloter un terminal muni d'un lecteur de carte a puce et connecte 
de fa?on classique a un reseau de type Internet, notamment en vu de realiser 
des demonstrations d'au moins une application enregistree dans la carte a 
puce. 

Pour ce faire, selon une caracteristique essentielle de l'invention, le 
logiciel de pilotage specifique a chacune des applications de demonstration est 
heberge par un serveur eloigne de type "WEB" connecte, egalement de fa?on 
classique, au reseau Internet. Le terminal, pour sa part, est muni d'une piece de 
logiciel particulier que Ton denommera ci-apres "specialise". Dans le contexte 
de Finvention, le terme "specialise" utilise pour cette piece de logiciel signifie 
seulement qu'il s'agit d'une piece de logiciel non standard qui doit etre 
implantee dans le terminal, mais en aucun cas qu'elle est specifique a 
rapplication en cours de demonstration. Tout au contraire cette piece de 
logiciel, d'un point de vue "application", est entierement generique et est 
independante de celle-ci, quelle qu'elle soit. 
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En outre, selon une autre caracteristique importante] la taille de la 
piece de logiciel necessaire peut etre tres reduite, pour des raisons liees a la 
nature des fonctions qui lui sont devolues et qui seront explicitees ci-apres. De 
ce fait, elle peut etre implantee une fois pour toutes dans le terminal et y resider 
a demeure, sans alterer de fagon significative les ressources informatiques 
propres au terminal, notamment sa capacite de memoire, en particulier si celui- 
ci est utilise pour d'autres taches. 

[.'invention presente done de nombreux avantages, et notamment les 
suivants : 

- une mise a jour simplifiee des demonstrations, puisque seuls les 
programmes heberges par le serveur distant doivent etre modifies : aucune 
intervention specifique sur les terminaux n'est plus necessaire ; 

- une configuration rapide et simple du terminal, qui peut etre un micro- 
ordinateur de type standard, muni d'un navigateur qui peut egalement fetre d'un 
type courant du commerce, souvent pre-installe, ce pour les memes raisons 
que celles precedemment rappelees (les donnees specifiques a la 
demonstration proprement dite etant localisees dans le serveur) ; 

- Tinterface graphique est standardised egalement puisque fournie par 
le navigateur dont les caracteristiques et le mode operatoire sont familiers a 
.Poperateur du terminal, meme si celui-ci n'a pas de connaissances particulieres 
en programmation ou en informatique ; et 

- le surcout et Taugmentation de la complexity dus aux dispositions 
specifiques a ('invention sont negligeables puisque r6duits ^ la seule 
implantation d'une piece de logiciel specialise, de taille reduite, implantation qui 
peut d'ailleurs, dans certaines circonstances, etre realisee une fois pourtoute. 

II s'ensuit que le systeme presente une grande universality puisque 
que le terminal peut virtuellement effectuer toutes les demonstrations d'une 
entreprise ou d'une society ce qu'elle que soit la carte a puce a presenter, d la 
seule condition que cette derniere soit d'un type normalisee pour etre 
compatible avec le terminal, ce qui en soi sort du cadre strict de Tinvention. Le 
systeme autorise egalement une grande fiabilite. 
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[.'invention a done pour objet principal un procede de pilotage a 
distance d'une station d'utilisateur via un reseau de type Internet, ladite station 
d'utilisateur etant munie d'un lecteur de carte a puce et comprenant une 
premiere pile protocolaire de communication, ledit lecteur de carte 3 puce 
comprenant une deuxieme pile protocolaire de communication et ladite carte a 
puce comprenant une troisieme pile protocolaire de communication, permettant, 
d'une part, des communications entre ladite station d'utilisateur et un serveur 
eloigne connecte au dit reseau et, d'autre part, des communications entre ladite 
station d'utilisateur et ladite carte a puce via ledit lecteur de carte a puce, ladite 
station d'utilisateur comprenant en outre des moyens de generation de requetes 
transmises au dit serveur eloigne, caracterise en ce qu'il comprend : 

- une premiere phase preliminaire de memorisation dans ledit serveur 
eloigne de donnees et/ou instructions permettant Felaboration de 
commandes specifiques sur reception de requetes specifiques 
provenant desdits moyens de generation de requetes et leur 
transmission a ladite station d'utilisateur ; 

- une deuxieme phase preliminaire de chargement dans ladite station 
d'utilisateur d'une piece de logiciel specialise formant interface entre 
lesdites premiere et deuxieme piles protocolaires, et destinee a traduire 
lesdites commandes specifiques re?ues par ladite station d'utilisateur en 
des commandes conformes a un premier protocole de communication 
determine ; 

- et au moins les etapes suivantes : 

a/ transmission au dit serveur eloigne d'au moins une requete 
specifique ; 

b/ generation par ledit serveur eloigne, sur reception d'une telle 
requete, d'au moins une desdites commandes specifiques et leur 
transmission a ladite station d'utilisateur selon un deuxieme protocole 
de communication determine ; 

c/ reception de cette commande specifique a ladite station 
d'utilisateur, interception par ladite piece de logiciel specialise et 
traduction dans ledit premier protocole de communication determine ; 
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6/ transmission de ladite commande traduite a ladite carte a puce 
selon ledit premier protocole de communication determine via ledit 
lecteur de carte a puce; et 

el activation par ladite commande traduite d'au moins une fonction 
determinee d'au moins une application enregistree dans ladite carte a 
puce, de maniere a realiser ledit pilotage. 
L'invention a encore pour objet une architecture de systeme pour la 
mise en oeuvre de ce procede. 

L'invention s'applique plus particulierement a I'application du procede et 
de I'architecture de systeme a un demonstrateur de carte a puce. 

L'invention va maintenant etre decrite de fa?on plus detailtee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1 iliustre schematiquement un exemple d'architecture de 
systeme d'application a base de carte a puce selon Tart connu ; 

la figure 2 iliustre de fa?on plus detaillee I'architecture logique d'un 
tel systeme ; et 

la figure 3 iliustre un exemple d'architecture pour le pilotage d 
distance d'un systeme ^application a base de carte a puce selon 
l'invention. 

Dans ce qui suit, sans en limiter en quoi que ce soit sa portee, on se 
"placera ci-apres dans le cadre de ('application preferee de l'invention, sauf 
mention contraire, c'est-a-dire ('application a un demonstrateur de carte a puce. 

On va tout d'abord rappeler brievement les caracteristiques techniques 
essentielles d'un systeme d'application a base de carte a puce. Celui-ci 
comporte generalement les elements principaux suivants : 
une carte a puce ; 

- un systeme hote constituant le terminal precite ; 

un reseau de communication, a savoir le reseau Internet dans 
1'application preferee ; 

- et un serveur d'application connecte au reseau Internet. 

La figure 1 iliustre schematiquement un exemple d'architecture de ce 
type. Le terminal 1 , par exemple un ordinateur individuel, comporte un lecteur 3 
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de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement integre dans le 
terminal 1 . La carte a puce 2 comporte un circuit integre 20 dont des connexions 
d'entrees-sorties affleurent en surface de son support pour autoriser une 
alimentation en energie electrique et des communications avec le terminal 1. Ce 
dernier comprend des circuits d'acces 1 1 au reseau Internet. II peut s'agir d'un 
modem pour se connecter a une ligne telephonique commutee ou a un reseau 
numerique a integration de services ( M RNIS M ), via par exemple un prestataire de 
. services Internet ("Internet Service Provider" ou "ISP", selon la terminologie 
anglo-saxonne). 

Le terminal 1 comprend naturellement tous les circuits et organes 
necessaires a son bon fonctionnement, et qui n'ont pas ete representes dans un 
but de simplification du dessin : unite centrale, memoires vive et fixe, memoire 
de masse a disques magnetiques, lecteur de disquette et/ou de CedeRom, etc. 

Habituellement, le terminal 1 est aussi relie a des peripheriques 
classiques, integres ou non, tels un ecran de visualisation 5, un clavier 6 et un 
pointeur 7, par exemple de type souris. 

Dans le cadre de I'invention, c'est grace notamment a la cooperation de 
ces terminaux que la demonstration pourra etre conduite. 

Le terminal 1 peut etre mis en communication avec des serveurs 
connectes au reseau Rl, dont un seul, 4, est illustre sur la figure 1. Les circuits 
" d^cces 1 1 mettent le terminal 1 en communication avec les serveurs 4 grace a 
un logiciel particulier 10, appele navigateur, ou "browser 11 selon la terminologie 
anglo-saxonne. Celui-ci permet d'acceder a diverses applications reparties sur 
Tensemble du reseau Rl t generalement selon un mode "client-serveur". 

Habituellement, les communications sur les reseaux s'effectuent 
conformement a des protocoles repondant a des standards comprenant 
plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de type 
Internet, les communications s'effectuent selon des protocoles specifiques a ce 
type de communication, mais qui comprennent aussi plusieurs couches 
logicielles. Le protocole de communication est choisi en fonction de Implication 
plus particulierement visee : interrogation de pages ""WEB"", transferts de 
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fichiers, courrier electronique (e-mel, ou "e-mail" selon la terminologie anglo- 
saxonne), forums ou "news", etc. 

L'architecture des reseaux de communication est decrite par diverses 
couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection"), 
defini par r "ISO", comporte sept couches qui vont des couches dites basses 
(par exemple la couche dite "physique" qui concerne le support de transmission 
physique) aux couches dites hautes (par exemple la couche dite "d'application"), 

• en passant par des couches intermediates, notamment la couche dite de 
"transport". Une couche donnee offre ses services a la couche qui lui est 
immediatement superieure et requiert de la couche qui lui est immediatement 
inferieure d'autres services, via des interfaces appropriees. Les couches 
communiquent a I'aide de primitives. Elles peuvent egalement communiquer 
avec des couches de meme < niveau. Dans certaines architectures, Tune ou 
I'autre de ces couches peut etre inexistante. 

Dans un environnement Internet, les couches sont au nombre de cinq, 
et de fa?on plus precise, en allant de la couche superieure a la couche 
inferieure : la couche ^applications ("http", "ftp", "e-mail", etc.), la couche de 
transport ('TCP"), la couche d'adressage de rSseau ("IP"), la couche de liens de 

donnees ("PPP", "Slip", etc.) et la couche physique. 

On va maintenant decrire, de fa?on plus detaillee, un exemple 

d'architecture typique pour un systeme d'application a' base de carte a puce 

selon Tart connu, par reference a la figure 2. Sur cette figure, on a decrit plus 

particulierement Tarchitecture logique en couches. 

Le terminal 1 comprend les circuits 11 d'acces au reseau Rl qui 

regroupent les couches logicielles inferieures Ci et C2, correspondant aux 

couches "physique" et de "lien de donnees" precitees. 

On a egalement represents les couches superieures C3 et C4, 

correspondant aux couches "d'adressage de reseau" ("IP") et de "transport" 

("TCP"). La couche superieure duplication ("http", "ftp", "e-mail", etc.) est 

schematisee par un navigateur "WEB" 10 de type quelconque, de preference de 

type standard du commerce. 
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^interface entre les couches inferieures, Ci et C2, et les couches 
superieures, C3 et C4, est constitute par une couche logicielle 15 generaiement 
appelee "driver couches basses". Les couches superieures, C3 et C4, 
s'appuient sur cette interface et sont mises en oeuvre par I'intermediaire de 
bibliotheques de fonctions specifiques ou bibliotheques reseau 14, avec 
lesquelles elles correspondent. Dans le cas du reseau Internet, 'TCP/IP 1 ' est mis 
en oeuvre au moyen de bibliotheques dites de "sockets". 

Cette organisation permet au navigateur 10 de poser des requetes vers 
un serveur eloigne 4, pour la consultation de pages "WEB" (protocole "HTTP"), 
pour le transfert de fichiers (protocole "FTP") ou renvoi de courrier electronique 
(protocole "e-mail"). 

Le terminal 1 comprend egalement le lecteur de carte 3, integre ou non. 
Pour communiquer avec la carte a puce 2, le lecteur de carte englobe 
egalement deux couches basses, CC1 (couche physique) et CC2 (couche de 
lien de donnees), jouant un role similaire aux couches C1 et C2- Les interfaces 
logicielles avec les couches CC1 et CC2 sont decrites, par exemple, par la 
specification "PC/SC" ("parte, service provider 11 ). Les couches elles-memes, 
CC1 et CC2, sont notamment decrites par les normes ISO 7816-1 a 7816-4. 

Une couche logicielle supplementaire 13 forme interface entre des 
• couches applicatives, sous la reference unique 16, et les couches inferieures, 
CC1 et CC2. La fonction principale devolue a cette couche 13 est une fonction 
de multiplexage/demultiplexage. 

L'architecture du terminal 1 decrite jusqu'a present est enti§rement 
commune a I'art connu. On a egalement represents sur la figure 2, en traits 
discontinus, un Element supplementaire 8, que Ton appellera "module 
specialise" et qui est specifique a ('invention. Ce module 8 est dispose entre la 
couche C4 et I'interface 13. La fonction de ce module sera explicitee ci-apres. 

Du cote de la carte a puce 2, on retrouve une organisation similaire a 
celle du terminal 1 , a savoir la presence de deux couches basses, references 
CC'1 (couche physique) et CC'2 (couche de lien de donnees), ainsi qu'une 
couche d'interface 23, tout a fait similaire a la couche 13. Cette couche 23 
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assure une interface entre les couches protocolaires CC'1 et CC'2 precitees et 
une ou plusieurs couches applicatives, representees sous la forme d'un module 
unique reference 26. 

Les communications entre le terminal 1 et la carte a puce 2 s'effectuent 
a Taide de commandes standardises. 

Differents protocoles sont utilisables, et a titre d'exemples non 
exhaustifs les suivants : 

- la recommandation ETSI GSM 11.11 ; 

- le protocole defini par la norme ISO 7816-3, en mode caractere T=0 ; 

- le protocole defini par la norme ISO 7816-3, en mode bloc T=1 ; 

- ou le protocole defini par la norme ISO 3309, en mode trame "HDLC" 
(pour "High-Level Data Link Control procedure 11 ou procedure de commande 
de liaison a haut niveau). 

Dans le cadre de ('invention, on utilisera de preference le protocole ISO 
7816-3, en mode bloc. 

De fa?on connue en soi, a chaque couche de protocole il est associe un 
certain nombre de primitives qui permettent les echanges de donn£es entre 
couches de meme niveau et d'une couche a Tautre. 

Dans Petat actuel de la technique, il n'est pas possible de mettre en 
communication directe la carte a puce avec un serveur eloigne 4, via le reseau 
Internet Rl. Aussi, comme il a ete rappele, pour effectuer une demonstration 
d'une ou plusieurs applications enregistrees de la carte a puce 2, il a ete 
propose dans I'art connu, soit d'implementer dans le terminal 1 des logiciels 
specifiques, soit de les telecharger a partir d'un serveur eloigne, sous la forme 
de "plug-ins". Ces solutions presentent de nombreux inconvenients, qui ont 6te 
egalement rappeles. 

On va maintenant decrire une architecture de systeme conforme a 
Tinvention et permettant de pallier ces inconvenients, par reference a la figure 3. 

A I'exception de dispositions specifiques a Tinvention, ('architecture 
presentee sur la figure 3 reprend Tessentiel de la configuration materielle et 
logique des figures 1 et 2. Aussi, il n'a ete represents sur cette figure que les 
elements indispensables a la bonne comprehension de invention. En outre, les 
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Elements communs a ces figures portent les memes references et ne seront re- 
decrits qu'en tant que de besoin. 

On doit bien comprendre egalement que la carte a puce 2 ne necessite 
aucune adaptation. Les communications entre le terminal 1 et celle-ci 
s'effectuent, comme dans Tart connu, en utilisant les jeux de commandes 
normalisees qui viennent d'etre decrits succinctement. 

Aussi, dans un but de simplification du dessin, les differentes couches 
protocolaires de communication, en soi communes a Tart connu, n'ont pas ete 
representees. 

Selon une premiere caracteristique importante de I'invention, I'essentiel 
des informations et codes necessaires pour effectuer une demonstration d'une 
carte a puce particuliere, et de fa?on plus generate pour piloter une telle carte a 
puce, est localise, non plus dans le terminal 1, sous quelque forme que ce soit 
(programme ou "plug-ins" specifiques telecharges), mais dans le serveur 
eloigne 4. 

Selon une deuxieme caracteristique importante de Tinvention, on prevoit 
un module specialise 8 dans le terminal 1. Cependant, il doit etre bien compris 
que le terme "specialise" a une signification particuliere dans le cadre de 
(•invention. Ce module 8 est dispose entre la couche C4 de la pile protocolaire 
du terminal 1 et interface 13 (voir figure 2), comme il a ete precedemment 
indique. II est constitue avantageusement d'une piece de logiciel et a pour 
fonctions essentielles de realiser une interface entre le reseau Internet Rl et le 
lecteur de carte a puce 3, d'une part, et de traduire des commandes reqxies du 
serveur 4, via le reseau Internet Rl t en commandes normalisees conformes aux 
normes ISO precitees. En ce sens, le module 8 est "generique" par nature, car 
entierement independant de Tapplication ou des applications enregistrees sur la 
carte a puce 2. En outre, du fait des fonctions qui lui sont devolues, la quantity 
de code necessaire est tr6s reduite en pratique. 

De fa?on plus detaillee, le serveur eloigne 4 comprend, par exemple, 
outre des moyens de traitement de donn§es informatises classiques (non 
representes), un serveur "HTTP" 40 proprement dit et des organes de 
memorisation, 41 et 42, que Ton a representes arbitrairement distincts. 
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Un premier organe de memorisation 41 permet de stocker des feuilles 
d'affichage, que Ton appellera "statiques", par exemple dans un format de type 
"HTML" ou autres ("XML", etc.). 

Le second organe de memorisation, reference 42, est destine plus 
particulierement a stocker des donnees representant les contextes de la ou des 
cartes a puce objet(s) d'une demonstration. Un "contexte carte a puce" est une 
representation en memoire de la carte a puce 2 au niveau du serveur eloigne 4. 
• Le contexte carte a puce comprend par exemple le numero de version du 
systeme d'exploitation commandant la carte a puce ou "operating system" selon 
la terminologie anglo-saxonne. L'organe de memorisation 42 permet de stocker 
egalement des donnees ou instructions permettant d'elaborer un jeu de 
commandes specifiques necessaires aux demonstrations precitees de carte a 
puce 2. Ces commandes specifiques vont etre interceptees par le module 
specialise 8 et traduites, de fa?on a pouvoir etre comprises par la carte a puce 2 
lorsqu'elles lui seront transmises. 

Les principales etapes du procede selon I'invention sont decrites ci- 

apres. 

De fagon classique en soi, le terminal permet notamment de mettre la 
carte a puce sous tension, via le lecteur de carte a puce 3, et, de fa?on plus 
generate, de Tinitialiser. De fa?on plus precise, c'est le module specialist 8 qui 
met la carte a puce 2 sous tension, par I'intermediaire d'un script execute dans 
le serveur eloign^ 4. Le navigateur "WEB" 10 permet, egalement de fagon 
classique, de poser des requetes vers le serveur eloigne 4, via un modem 1 1 ou 
un organe similaire, un canal classique de transmission 100 (ligne telephonique 
ou autre) et le reseau Internet RL Le chemin de transmission passe 
habituellement par un prestataire de service, eventuellement un "coupe-feu" 
("firewall") et/ou un systeme dit "proxy" (non representes). A titre d'exemple, la 
requete posee permet d'afficher la page d'accueil tfun site "WEB" sur Tecran 5 
et, ensuite, de naviguer dans ce site, par affichages successifs de pages, selon 
les options presentees. 

La requete transmise au serveur eloigne 4 peut permettre egalement 
tfafficher des pages en langage "HTML" relatives £ la carte a puce 2, pages 
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associ6es £ la demonstration en cours et stockees dans Porgane de 
memorisation 41. 

De fa?on plus particuliere a I'invention, la requete transmise au serveur 
eloigne 4 a pour resultat la generation par celui-ci d'un jeu de commandes 
specifiques destinees a la manipulation de la carte a puce 2 en cours de 
demonstration. 

En effet, certaines requetes specifiques sont reconnues comme telles 
par le serveur 40 et sont traitees dans le cadre du contexte de la carte a puce 
en memoire dans I'organe 42. II est a noter que le contexte de la carte a puce 2 
est mis a jour, par exemple lors de la mise sous tension de la carte a puce 2, par 
utilisation du signal dit de "RESET de cette derniere. 

De fason.classique en soi, ('elaboration des commandes generees par 
le serveur 40 peut etre le resultat de I'execution d'un script de type "CGI" (pour 
"Common Gate Interface"). II s'agit d'un processus bien connu de I'Homme de 
metier dans le domaine des communications de type "client-serveur" sur le 
reseau Internet. A titre d'exemple, lorsqu'une requete de type formulaire est 
transmise a un serveur "WEB", celle-ci est transmise via une "passerelle" a un 
repertoire habituellement appele "cgi-bin" dans lequel sont enregistres des 
scripts. Les donnees resultats de I'execution d'un script particulier sont 
retransmises par le chemin inverse et envoyees au "client" ayant emis la 
• requete, en I'occurrence sous forme de commandes specifiques transmises au 
terminal 1. 

Cependant, comme il a ete rappele, la carte a puce 2 ne peut pas 
communiquer directement avec le reseau Internet Rl et, en particulier, ne peut 
done pas recevoir, ni a fortiori interpreter les commandes emises par le serveur 
40. Ces commandes sont transmises, de fa?on habituelle dans des paquets, 
I'adresse "IP" de destination etant celle du terminal 1, e'est-a-dire le "client". De 
meme, sauf a implanter un "plug-in" specialise dans le navigateur 10, ce dernier 
ne peut pas communiquer directement avec la carte a puce 2. 

Le module specialise 8 forme interface, par un premier cote, avec les 
couches protocolaires hautes du terminal 1 , c'est-3-dire C4 (voir figure 2). Les 
commandes specifiques revues par le terminal 1 sont interceptees et 
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"comprises' 1 par le module 8 comme lui etant destinees. Selon Tun des 
caracteristiques essentielles de 1'invention, ce dernier les traduit en un jeu de 
commandes conforme aux normes ISO precitees. Les autres commandes 
regues ne sont pas traitees par ce module 8 et transmises, de fagon classique, 
5 au navigateur 10. Le serveur 4 dispose d'une connexion distincte 80 avec le 
module specialise 8. Cette connexion peut etre securisee et supporter un 
chiffrage du type dit "SSL" (pour "Secure Socket Layer"). 

De fa?on schematique, pour mieux mettre en evidence le processus 
' propre a I'invention, on a illustre la communication qui s'etablit entre le reseau 
10 Internet et le module 8 par un canal separe 80, represents en traits pointilles. 
Cependant, on doit bien comprendre que toutes les communications passent 
par les canaux de transmission habituels, et s'effectuent selon des protocoles 
de transmission normalises (par exemple 'TCP/IP" pour le module specialise 8 
et "HTTP" pour le navigateur 10). 
1 5 Le module 8 forme egalement interface, par un second cote, avec le 

lecteur de carte a puce 3. II transmet done a celui-ci les commandes qu'il a 
re?ues et traduites. Ces commandes sont d§chiffr§es si necessaires (si la 
liaison etait securisee) et traduites. Elles sont done desormais comprehensibles 
par la carte a puce 2. En effet, apres traduction, les commandes retransmises a 
20 la carte a puce 2, via le lecteur 3, sont au format ISO 7816-4 et sont done 
compatibles avec le mode de communication utilise entre le lecteur de carte a 
puce 3 et la carte a puce 2. 

Les commandes ainsi transmises a la carte a puce 2 permettent, par 
exemple, une mise sous-tension de la carte a puce 2, d'activer fa ou les 
25 applications memorisees dans celle-ci, par exemple pour executer des fonctions 
particulieres et/ou lire des fichiers specifiques enregistres dans celle-ci. En 
retour, la carte a puce 2 transmet au module specialise 8, via le lecteur de carte 
a puce 3, des commandes et/ou instructions qui permettront, dans une etape 
ulterieure, I'affichage sur Tecran 5 de differentes donnees propres a la carte a 
30 puce 2 en cours de demonstration. Cependant, ces commandes et/ou 
instructions sont tout d'abord traduites par le module specialise 8, transmise au 
serveur 4, et retransmises au terminal 1 et au navigateur 10. 
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Le module specialise 8 est un serveur de type "TCP/IP" qui repoit des 
requetes 'TCP/IP" en provenance d'un script execute dans le serveur 40. La 
communication avec le module specialise 8 s'insere dans une requete entre le 
navigateur 10 et le serveur 40. Ce script est charge d'executer une succession 
de commandes a destination du module specialise 8. Ce dernier agit alors 
comme un serveur "TCP/IP" et renvoie une reponse pour chaque commande 
"TCP/IP" re?ue du serveur 40. Le script precite, qui peut faire appel a un 
processus du type dit "CGI M (pour "Common Gate Interface") ou "Servlet Java" 
' (marque deposee), traite ('ensemble des reponses "TCP/IP" du module 
specialise 8. Ensuite, il formate une reponse de type "HTTP" transmise au 
navigateur 10. Ainsi un utilisateur (non represented par exemple le proprietaire 
de la carte a puce 2, peut interagir avec cette carte a puce 2 par ('intermediate 
du navigateur 10, de scripts associes au serveur 40, du module specialise 8 et 
du lecteur de la carte a puce 3. 

Le navigateur 10 permet de visualiser le contenu de la carte a puce 2. 
On constate done que la carte a puce 2 est en realite pilot6e 
directement par un processus du type "CGI" et un contexte carte memorise dans 
le serveur 4. Tout se passe done comme si la carte a puce 2 etait en 
communication directe avec ce dernier et recevait des requetes du reseau 
Internet Rl. 

Pour fixer les idees, pour effectuer les taches qui lui sont devolues, le 
module 8 a une taille typique de 50 KO. II peut etre charge dans les moyens de 
memorisation (non represents) dont est pourvu le terminal 1, avant le debut 
d'une demonstration, de fa?on tres rapide compte tenu de sa tres faible taille, a 
I'aide d'une disquette par exemple, ou a partir de tout autre support 
d'enregistrement. Mais il peut etre aussi etre laisse a demeure sans 
inconvenients, apres un chargement initial, ce pour la meme raison et sans 
oberer de fagon significative les ressources du terminal, notamment les 
ressources memoires de celui-ci. Toujours du fait de sa faible taille, il est 
Sgalement possible de le telecharger a partir du serveur eloign^ 4, ou de tout 
autre serveur "WEB". Avec les technologies actuelles, meme en utilisant une 
simple ligne telephonique de type commute, en ayant recours d un modem 
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rapide (56 K), le telechargement d'un programme de cette taille ne necessite 
que quelques dizaines de secondes. Cette methode presente I'avantage, de 
toujours disposer de la derniere version du programme specialise disponible, 
constituant le module 8. 

On constate aisement qu'il n'est pas necessaire que I'operateur possede 
des connaissances particulieres en programmation. L'interface graphique, qui 
est celle du navigateur "WEB" 10, qui peut etre avantageusement d'un type bien 
connu du commerce, lui est tout a fait familiere. II lui suffit de connaitre I'adresse 
Internet du site "WEB" sur lequel il doit se connecter, adresse qui peut etre mise 
au prealable en memoire du navigateur 10, dans une liste dite de "favoris" ou 
appellations similaires, generalement connues sous la terminologie anglo- 
saxonne de "bookmarks". 

Le serveur 4 pouvant stocker, comme il a ete indique, des pages dites 
statiques en langage "HTML", les differentes etapes de la demonstration £ 
realiser peuvent etre affichees sous forme d'un menu constitue d'hyperliens, 
I'operateur selectionnant Tune ou I'autre des options presentees, a I'aide du 
clavier 6, ou en cliquant dessus a I'aide de la souris 7. 

Cependant, pour faciliter encore plus le deroulement de la 
demonstration, et I'automatiser d'avantage, il est egalement possible de 
telecharger, dans le navigateur 10, une appliquette, ou "applet" selon la 
terminologie anglo-saxonne, par exemple sous la forme d'une piece de logiciel 
en langage "JAVA" dont la taille est tres reduite. Cet "applet" permet de gerer le 
deroulement de la demonstration en transmettant les requetes necessaires au 
serveur 4, qui a son tour genere des commandes specifiques au module 
specialise 8, puis transmet le resultat de calculs qu'il effectue au navigateur 10, 
sous la forme d'une reponse "HTTP". Dans ce cas, Fessentiel du travail de 
Toperateur pourra se resumer a se connecter au serveur 4 et eventuellement, si 
besoin est, dans une phase initiate, a charger ou a telecharger, la piece de 
logiciel constituant le module specialise 8, apres avoir mis sous tension le 
terminal 1 et avoir introduit la carte a puce 2 dans le lecteur 3. 

A la lecture de ce qui precede, on constate aisement que I'invention 
atteint bien les buts qu'elle s'est fixes. 
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La carte a puce ne necessite aucune adaptation. Le terminal de 
demonstration peut etre un micro-ordinateur du commerce ou un appareil 
similaire. II ne necessite pas non plus d'adaptation particuliere. La seule 
contrainte specifique a invention reste tres limitee : il est seulement necessaire 
5 de proceder au chargement, dans une phase preliminaire, d'une piece de 
logiciel de faible taille, piece de logiciel entierement independante de 
I'application ou des applications enregistrees sur la carte a puce en cours de 
demonstration. Comme il a ete indique, cette piece de logiciel peut etre chargee 
' une fois pour toute. Elle peut etre egalement telechargee a partir du reseau 
io Internet. II s'ensuit que la configuration d'une station de demonstration est 
reduite a sa plus simple expression et ne necessite aucune competence 
particuliere, ce qui contribue egalement a rendre le procede particulierement 
economique. 

^interface graphique est familiere a tout operateur, puisqu'il s'agit de 
15 celle associe a un navigateur "WEB", qui peut etre avantageusement de type 
courant. 

Le procede permet une grande souplesse et une grande universalite. 
En effet, les donnees specifiques a une ou plusieurs demonstrations sont 
stockees dans un serveur eloigne et sont susceptibles d^tre utilisees par un 

20 grand nombre de stations. La mise a jour d'une demonstration donnee et/ou 
Tajout d*une ou plusieurs demonstrations s'effectuent tres simplement, puisque 
seul ie serveur eloigne stockant les donnees et les programmes necessaires & 
ces demonstrations est concerne. 

Le procede permet en outre un mode interactif entre des pages, par 

25 exemple de type "HTML", fournies par le serveur eloigne, et des informations et 
donnees provenant de la carte 3 puce, sous le controle de commandes et 
requetes provenant directement de ce meme serveur, et transmises apres 
traduction par la piece de logiciel speciaiisee a la carte a puce, via le lecteur. 

II doit etre clair cependant que invention n'est pas limitee aux seuls 

30 exemples de realisations explicitement decrits, notamment en relation avec 
Tarchitecture illustree par la figure 3. 
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Enfin, bien que le proc§de et ('architecture aient ete decrits de fa?on 
detaillee dans le cas d'un demonstrates de carte a puce, invention n'est en 
aucun cas limite a cette application particuliere. 

L'invention peut trouver application a chaque fois que Ton desire piloter 
une station comprenant un terminal et un lecteur de carte a puce, via le reseau 
Internet ou un reseau de type similaire : intranet, extranet. 
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REVENDICATIONS 

1. Procede de pilotage a distance d'une station d'utilisateur via un r6seau de 
type Internet, ladite station d'utilisateur etant munie d'un lecteur de carte a puce 
et comprenant une premiere pile protocolaire de communication, ledit lecteur de 
carte a puce comprenant une deuxieme pile protocolaire de communication et 
ladite carte a puce comprenant une troisieme pile protocolaire de 
communication, permettant, d'une part, des communications entre ladite station 
d'utilisateur et un serveur eloigne connecte au dit r^seau et, d'autre part, des 
communications entre ladite station d'utilisateur et ladite carte a puce via ledit 
lecteur de carte a puce, ladite station d'utilisateur comprenant en outre des 
moyens de generation de requetes transmises au dit serveur §loigne, 
caracterise en ce qu'il comprend : 

- une premiere phase preliminaire de memorisation (42) dans ledit 
serveur eloigne (4) de donnees et/ou instructions permettant 
('elaboration de commandes specifiques sur reception de requetes 
specifiques provenant desdits moyens de generation de requetes (10) et 
leur transmission a ladite station d'utilisateur (1 ) ; 

- une deuxieme phase preliminaire de chargement dans ladite station 
d'utilisateur (1) d'une piece de logiciel specialise (8) formant interface 
entre lesdites premiere et deuxieme piles protocolaires, et destinee a 
traduire lesdites commandes specifiques re?ues par ladite station 
d'utilisateur (1) en des commandes conformes a un premier protocole de 
communication determine ; 

- et au moins les etapes suivantes : 

a/ transmission au dit serveur eloigne d'au moins une requete 
specifique ; 

b/ generation par ledit serveur eloigne (4), sur reception d'une telle 
requete, d'au moins une desdites commandes specifiques et leur 
transmission a ladite station d'utilisateur (1) selon un deuxieme 
protocole de communication determine ; 
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cl reception de cette commande specifique a ladite station 
d'utilisateur (1), interception par ladite piece de logiciel specialise (8) 
et traduction dans ledit premier protocole de communication 
determine ; 

5 d/ transmission de ladite commande traduite a ladite carte a puce (2) 

selon ledit premier protocole de communication determine via ledit 
lecteur de carte a puce (3) ; et 

el activation par ladite commande traduite d'au moins une fonction 
determinee d'au moins une application (26) enregistr§e dans ladite 
to carte a puce (2), de maniere a realiser ledit pilotage. 

2. Precede selon la revendication 1 , caracterise en ce que lesdites donnees 
et/ou instructions memorisees dans ledit serveur eloigne (4) et permettant 
('elaboration de commandes specifiques comprennent des donnees dites de 
contexte de carte a puce, ledit contexte 6tant une representation, dans la 

15 memoire dudit serveur eloigne (4), de ladite carte a puce (2) presente dans 
ladite station d'utilisateur (1). 

3. Procede selon la revendication 2, caracterise en ce que ladite carte a puce 
(2) etant commandee par un systeme d'exploitation associ§ a un numero de 
version, ledit contexte comprend au moins ledit numero de version du systeme 

20 Sexploitation. 

4. Procede selon la revendication 1, caracterise en ce qu'il comprend en 
outre, suite a ladite etape d'activation, au moins : 

f/ une etape de transmission de donnees et/ou instructions entre 
ladite carte a puce (2) et ledit terminal (1), via ledit lecteur de carte a 
25 puce (3), ladite transmission s'effectuant selon ledit premier protocole 

de communication determine ; 

g/ une etape de traduction desdites donnees et/ou instructions par 
ladite piece de logiciel specialise (8) et leur transmission vers ledit 
serveur eloigne (4), selon ledit deuxieme protocole de communication 
30 determine ; 
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hi une etape de traitement de ces donnees et/ou instaictions par ledit 
serveur §Ioign6 (4) ; 

i/ une etape d'elaboration par ce serveur (4) de donnees 
caracteristiques d'une configuration de ladite carte a puce (2) et/ou 
d'une application enregistr6e dans cette carte a puce (2) et de 
transmission desdites donnees caracteristiques audit terminal (1) 
suivant un troisieme protocole de communication determine ; et 
j7 une etape d'affichage, sur un ecran de visualisation (5) connecte au 
dit terminal (1), desdites donn6es caracteristiques. 

5. Procede selon la revendication 4, caracterise en ce que lesdits moyens de 
generation de requetes etant constitues par un navigateur de type "WEB" (10), il 
comprend une troisieme phase preliminaire consistant a enregistrer dans ledit 
serveur eloigne (4) des donnees constituant des pages d'affichage dites 
statiques, et des etapes subsequentes comprenant la transmission, selon ledit 
troisieme protocole de communication determine, sur reception de requites 
specifiques generees par ledit navigateur (10), de tout ou partie de ces donnees 
au dit terminal pour afficher des pages d'information associees a ladite carte a 
puce (2) sur ledit ecran de visualisation (5). 

6. Procede selon la revendication 5, caracterise en ce qu'il comprend une 
quatrieme phase preliminaire consistant a generer, a Taide dudit navigateur 
(10), une requete particuliere transmise a un serveur eloigne connects au dit 
reseau Internet (/?/), en vu de telecharger une pi6ce particuliere de logiciel dite 
appliquette dans le navigateur (10), de maniere a automatiser tout ou partie 
desdites etapes a/ a j/. 

7. Procede selon la revendication 6, caracterise en ce que ladite appliquette 
est ecrite en langage "JAVA" (marque deposee). 

8. Procede selon la revendication 1, caracterise en ce que lesdites 
commandes specifiques sont le resultat de ('execution d'un script de type "CGI" 
dans ledit serveur eloigne (4). 
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9. Procede selon la revendication 1, caracterise en ce que ladite piece de 
logiciel specialise (8) est chargee dans ladite station d'utilisateur (1), pendant 
ladite premiere phase preliminaire, a partir d'un support d'enregistrement de 
donnees. 

5 10. Procede selon la revendication 1, caracterise en ce que ladite piece de 
logiciel specialise est telechargee dans ladite station d'utilisateur (1), pendant 
ladite premiere phase preliminaire, a partir d'un serveur eloigne, via ledit r6seau 
Internet (R/). 

11. Procede selon la revendication 1, caracterise en ce que ledit premier 
10 protocole de communication determine est du type 'TCP/IP". 

12. Procede selon la revendication 1, caracterise en ce que ledit deuxieme 
• protocole de communication determine est conforme aux normes ISO 7816-1 £ 

7816-4. 

13. Procede selon la revendication 4, caracterise en ce que ledit troisieme 
15 protocole de communication determine est du type "HTTP". 

14. Architecture de systeme de pilotage a distance d'une station d'utilisateur 
(1) via un reseau de type Internet (Rl) t ladite station d'utilisateur (1) 6tant munie 
d'un lecteur de carte a puce (3), et comprenant une premiere pile protocolaire 
de communication, ledit lecteur de carte a puce (3) comprenant un deuxieme 

20 pile protocolaire de communication et ladite carte a puce (2) comprenant une 
troisieme pile protocolaire de communication, permettant, d'une part, des 
communications entre ladite station d'utilisateur (1) et un serveur eloigne (4) 
connecte au dit reseau et, d'autre part, des communications entre ladite station 
d'utilisateur (1) et ladite carte a puce (2) via ledit lecteur de carte a puce (3), 

25 ladite station d'utilisateur (1) comprenant en outre des moyens de generation 
de requetes (10) transmises au dit serveur eloigne (4), caracterisee en ce que 
ledit serveur eloigne (4) est muni de moyens de memorisation (41, 42) 
permettant le stockage de donnees et/ou instructions permettant ('elaboration de 
commandes specifiques sur reception de requetes sp§cifiques provenant 
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desdits moyens de generation de requetes (10) et leur transmission a ladite 
station d'utilisateur (1) et en ce que ladite station d'utilisateur (1) est munie d'un 
module supplemental (8), dit specialise formant interface entre lesdites 
premiere et deuxieme piles protocolaires, et destine a traduire lesdites 
commandes specifiques regues par ladite station d'utilisateur (1), selon un 
premier protocole de communication determine, en des commandes conformes 
a un deuxieme protocole de communication determine, de maniere a ies 
transmettre, selon ledit deuxieme protocole de communication determine, via 
ledit lecteur de carte a puce (3), a ladite carte a puce (2), pour activer au moins 
une fonction determinee d'au moins une application enregistree dans cette carte 
a puce (2). 

15, Architecture de systeme selon la revendication 14, caracterisee en ce que 
ledit serveur eloigne (4) comprend un serveur "HTTP" (40), des premiers 
moyens de memorisation (42) pour le stockage desdites donnees et/ou 
instructions permettant ('elaboration de commandes specifiques et des seconds 
moyens de moyens de memorisation (41) pour le stockage de donnees 
constituant des pages d'affichage en langage "HTML". 

16. Application de Parchitecture systeme selon la revendication 14, £ la 
realisation d'un demonstrates de carte a puce (2), ladite station d'utilisateur (1) 
comprenant un ecran de visualisation (5) pour I'affichage de donnees 
transmises par ledit serveur eloigne (4) audit module supplemental (8) et 
caracteristiques d'un contexte de ladite carte a puce (2), suivant un troisieme 
protocole de communication determine, lesdites donnees caracteristiques etant 
elaborees par ledit serveur eloigne (4) sur reception de donnees emises par 
ladite carte a puce (2), selon ledit deuxieme protocole de communication 
determine, traduites par ledit module supplemental (8) et transmises a ce 
serveur eloigne (4), selon ledit premier protocole de communication determine. 
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